Migration einer veralteten Power-Builder Applikation in eine moderne Java Applikation

Hier wird die automatische Transformation einer Power-Builder Applikation aus den 90er Jahren mit einer Zwei-Schichten-Client/Server-Architektur in ein modernes Java-Anwendungssystem mit drei Architekturschichten geschildert. Neben der Umsetzung der Power-Builder GUI-Oberflächen in Java-SWT Oberflächen wird die Verarbeitungslogik aus den PowerBuilder Thick-Client Modulen entfernt und in Java Transformationsklassen versetzt. Auf der Datenbankseite werden die PL-SQL Stored-Procedures aus der Datenbank entfernt und in Java Zugriffsklassen versetzt. Dadurch entsteht eine neue Architekturschicht zwischen den jetzt verdünnten Client-Oberflächen und der abgemagerten Datenbankstruktur, die frei von der Zugriffslogik ist. Zur Zeit ist die Umsetzung nur teils automatisiert; die vollautomatische Transformation ist aber noch für dieses Jahr geplant. 1 Die Ausgangslage: Power-Builder & PL/SQL Anfang der 90er Jahre war Power-Builder von Sysbase ein weitverbreitetes Tool zur Erstellung von graphischen Oberflächen für C++ Systeme, da C++ selbst keine adäquate Unterstützung dafür anbot. Power Builder hat ein vorgefertigtes Bildschirm-Verarbeitungsobjekt (data window), das Methoden für die Erzeugung, Editierung und Anzeige von Bildschirmdaten enthält. Der Entwickler kann diese Funktionen erben und seinen spezifischen Bedürfnissen anpassen, ohne alles von Grund auf programmieren zu müssen. Außerdem bietet es eine Reihe vorgefertigter DatenbankZugriffsfunktionen im Sinne von ODBC an. Mit Power-Builder konnte man Menüs, Buttons, ScrollBars und die üblichen Oberflächenelemente der ersten GUI-Generation implementieren. Darüber hinaus konnte man auch Kontrolllogik in die Oberflächensteuerungsmodule einbauen, um Eingabedaten zu prüfen, einfache Verarbeitungsregeln zu kodieren, Datenbankaufträge abzusenden und Ausgabedaten zu formatieren. Komplexere Verarbeitungsregeln sowie die Zugriffsoperationen wurden als Stored-Procedures in der Datenbank implementiert. Auf dieser Weise entstand eine Zwei-Schichten-Architektur mit vorne einer dicken Client-Schicht, in der ein Teil der Verarbeitung stattfand, und hinten einer dicken Server-Schicht, in der sich der Rest der Verarbeitung abspielte. Wenn man davon ausgeht, dass die Oberfläche nur als Fenster zur Datenhaltung dienen sollte, war diese Lösung ausreichend. Das Datenbanksystem diente als Server und steuerte die mehrfachen Zugriffe auf die gleichen Daten. Wenn man aber dazu übergeht, mehr Verarbeitungslogik in das System hineinzupacken, stößt diese Architektur bald an ihre Grenzen. Die Oberflächen sind überlastet, und die Clientmodule werden immer komplexer. Außerdem ist die Applikation durch den begrenzten Vorrat an verfügbaren graphischen Elementen der damaligen Zeit eingeschränkt. Neuere graphische Eigenschaften kann man nicht in Anspruch nehmen, weil sie vom alten Tool nicht unterstützt werden. Auf der Datenbankseite wächst die Komplexität der Stored Procedures in dem Maße wie immer mehr Bedingungen und Prüfungen eingebaut werden. Sie erreichen den Punkt, an dem sie nicht mehr handhabbar sind. Hinzu kommt, dass es keine allgemeingültige Stored Procedure Sprache gibt: Jeder Datenbankanbieter hat eine eigene. Wenn so viel Logik in den Stored Procedures steckt, ist es unmöglich, sich jemals von dem jeweiligen Datenbanksystem zu lösen – der Anwender sitzt in der proprietären Falle. Er kommt nur weg, wenn er die ganzen Stored Procedures aus der Datenbank entfernt. Also ein Grund mehr, sich von der Zwei-Schichten-Architektur zu trennen. Der ausschlaggebende Grund ist jedoch, dass PowerBuilder nicht mehr unterstützt wird. Das Produkt ist tot. 2 Die vorgesehene Lösung Als Ablösung zur oben geschilderten Situation ist eine neue Vier-Schichten-Architektur mit einer allgemeingültigen, nicht-proprietären Programmiersprache vorgesehen. In der Client-Schicht werden die Power-Builder Oberflächenmodule mit Verarbeitungslogik durch JavaSWT Klassen ohne Verarbeitungslogik abgelöst. Die Verarbeitungslogik wird in Java Transformationsklassen versetzt. Diese Transformationsklassen bilden eine neue Mittelschicht. In der Datenbankschicht werden die PL/SQL Prozeduren aufgelöst und deren Inhalt in JavaAbbildung 1: Neue 4-Schichten-Architektur Hibernate Zugriffsklassen versetzt. Diese Zugriffsklassen bilden eine weitere neue Mittelschicht. Die neue Clientschicht enthält nur die Oberflächenobjekte und deren Methoden. Sie ist frei von Applikationslogik. Die neue Datenschicht enthält nur die Datentabellen und ist somit austauschbar. Die zwei neuen Mittelschichten sind unabhängig voneinander und verleihen dem System ein hohes Maß an Flexibilität, Portabilität und Wiederverwendbarkeit (siehe Abb. 1). 3 Der Transformationsprozess Für den Übergang von der alten Architektur mit den alten Sprachen in die neue Architektur mit den neuen Sprachen wurden drei Parallelprozesse mit jeweils n Schritten definiert: Ein Eingabe-getriebener Prozess, ein Ausgabe-getriebener Prozeß, und ein Umsetzungsprozess. Da die Zeit knapp war, liefen alle drei Prozesse nebeneinander her und bedienten sich gegenseitig. Abbildung 2: Drei parallele Prozesse Reverse Engineering: Der Eingabe-getriebene Prozess geht, wie die Benennung impliziert, von der Transformationseingabe aus, d.h. von dem bestehenden PowerBuilderund PL/SQL-Source. Er wird von einem Power-Builderund PL/SQL-Experten ausgeführt. 1) Die Power-Builderund PL/SQL-Sourcen werden statisch analysiert, um deren Größe, Komplexität und Qualität zu messen und deren Mängel und Schwachstellen zum Vorschein zu bringen. 2) Die Power-Builderund PL/SQL-Sourcen werden automatisch nachdokumentiert und deren Inhalte in Tabellen abgelegt: Eine Tabelle für jede Oberfläche mit einem Eintrag für jedes Oberflächenobjekt, eine Tabelle für jedes Datenbankobjekt mit einem Eintrag für jedes Attribut, eine Tabelle für jede PowerBuilder Oberflächenprozedur mit einem Eintrag für jede Anweisung, und eine Tabelle für jede PL/SQL Prozedur mit einem Eintrag für jede Anweisung. 3) Die Inhalte der Datentabellen werden verfeinert und die Namen der Daten ausgebessert. 4) Die Anweisungen in den Prozedurtabellen werden refaktoriert und die GoTo-Sprünge entfernt. 5) Die Oberflächentabellen werden in Tabellen mit nur Maskenanweisungen und Tabellen mit Verarbeitungsanweisungen geteilt. Das Ergebnis dieses Prozesses ist eine Menge Datenund Prozedurbeschreibungstabellen. Forward Engineering: Der Ausgabe-getriebene Prozess geht von der Transformationsausgabe aus, d.h. von dem zu erstellenden Java-Source. Er wird von einem Java-Experten ausgeführt. 1) Ein Template für die Java-SWT-Klassen wird erstellt  gleiches Muster für alle UI-Klassen. 2) Ein Template für die Java-Hibernate-Klassen wird erstellt  gleiches Muster für alle Zugriffsklassen. 3) Ein Template für die Java-Transformationsklassen wird erstellt  gleiche Struktur, soweit möglich. 4) Die Template-Klassen werden mit einem Testtreiber, Teststubs und künstlichen Testdaten getestet. Das Ergebnis dieses Prozesses ist eine Reihe von Java-